The technical field for the present invention is context transfer, especially in networks comprising access points.
Following documentation is regarded as state of the art:    [1] J. Kempf (ed), “Problem Description: Reasons for Performing Context Transfers Between Nodes in an IP Access Network” (RFC 3374); http://www.ietf.org/rfc/rfc3374.txt    [2] J. Loughney (ed), “Context transfer protocol”,IETF, Internet draft, October 2003; http://www.ietf.org/html.charters/seamoby-charter.html.    [3] G. Kenward (ed), “General Requirements for context transfer” IETF Internet draft, October 2002; http://www.ietf.org/html.charters/seamoby-charter.html.    [4]R. P. Swale et al., “Middlebox Communications (MIDCOM) Protocol Requirements”, IETF RFC 3304; http://www.ietf.org/rfc/rfc3304.txt    [5] B. Carpenter et al, “Middleboxes: Taxonomy and Issues”, IETF RFC 3234, 2002; http://www.ietf.org/rfc/rfc3234.txt    [6]P. Srisuresh, “Middlebox Communications (MIDCOM) Architecture and framework”, IETF RFC3303; http://www.ietf.org/rfc/rfc3303.txt    [7] R. Hancock (ed): Next Steps in Signalling: Framework”, IETF Internet draft, October 2003; http://www.ietf.org/html.charters/nsis-charter.html.    [8] G. Fodor, A. Eriksson, A. Tuoriniemi, “Providing QoS in Always Best Connected Networks”, IEEE Communications Magazine, Vol 41, No7, pp. 154-163, July 2003.    [9] J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF RFC 3261. http://www.ietf.org/rfc/rfc3261.txt.    [10] M. Handley et al. “SDP: Session Description Protocol”, IETF RFC 2327. http://www.ietf.org/rfc/rfc2327.txt.    [11] G. Camarillo (ed), “Integration of Resource Management and Session Initiation Protocol”, IETF RFC 3312.http://www.ietf.org/rfc/rfc3312.txt.    [12] K. El Malki (ed), “Low Latency Handoffs in Mobile IPv4”, IETF Internet Draft, October 2003.http://www.ietf.org/html.charters/mip4-charter.html.
For context transfer purposes, the organization IETF has developed the Context Transfer protocol (see references [1], [2], [3]). In these documents, the context is defined as the information on the current state of a service required to re-establish the service on a new subnet without having to perform the entire protocol exchange with the mobile host from scratch and Context transfer is defined as the movement of context from router or other network entity to another as a means of re-establishing specific services on a new subnet or collection of subnets.
In IP (Internet Protocol) access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. For example, Mobile IP networks allow a mobile node MN or an entire moving network to change acces router AR that provides the first IP layer hop seen from the mobile node or from a moving network's edge. When the MN changes AR (due to, for instance, mobility), there is a need to establish a new path, whose nodes should ideally provide similar treatment to the IP packets as was provided along the old routing path.
In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization and Acounting (AAA), header compression and Quality of Service (QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signalling flows from scratch. This process may in some cases considerably slow the process of establishing the mobile host on the new subnet.
Alternatively, IP flow related state information, the context, can be transferred to the new subnet. In the example above, context could be transferred from the old AR to the new AR in conjunction with inter-AR hand-over.
The IETF MIDCOM working group (WG) is examining scenarios and defining protocols for IP networks that contain entities that perform functions apart from traditional Layer 3 (L3) routing, so called middle-boxes (MB) (see for example references [4], [5], [6)]. A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and a destination host. Such middle-boxes may require a context that is specific to the functions and services they perform. For instance, a Quality of Service scheduler may need to maintain some token bucket state associated with an IP flow (QoS context), a firewall may need to know about a security association of an IP flow (security context), etc. For the moment, it is possible to list 22 different kind of middleboxes that could be provided along an end-to-end path.
Middleboxes embed application intelligence within the device to support specific application traversal. Middleboxes supporting the Middlebox Communication (MIDCOM) protocol will be able to externalize application intelligence into Midcom agents. Therefore, Midcom agents are logical entities which may reside physically on nodes external to a middlebox, possessing a combination of application awareness and knowledge of middlebox function. A Midcom agent may communicate and interact with one or more middleboxes. Said Midcom protocol between a Midcom agent and a middlebox allows the Midcom agent to invoke services of the middlebox and allow the middlebox to delegate application specific processing to the Midcom agent. Further, the protocol enables the middlebox to perform its operation with the aid of Midcom agents, without resorting to embedding application intelligence. The transfer of IP flow related state and context information is facilitated by the IETF Context Transfer protocol (see for example ref. [2)]. The proposed scope and protocol requirements do not consider scenarios where the context needs to be re-established at an arbitrary point within an IP network that supports middleboxes. For instance in the mobile IP scenario, when the end-to-end path changes during the lifetime of a session, the involved middleboxes may also change upon hand-over. When a particular IP flow is moved from one path to another, new firewalls and packet schedulers may be involved along the new path. In such situations, context needs to be communicated to these new in-path middleboxes rather than just from the “old” access router AR to the “new” access router AR. In fact, the “old” or “new” may not even know which middleboxes along the new path that require to re-establish what type of context (firewall, QoS scheduler, etc) after a mobile IP hand-over.
The particular end-to-end path, along which some middleboxes may need context can traverse multiple operator domains. Herein, a domain or administrative (operator) domain is the collection of hosts, routers, middleboxes and the interconnecting networks managed by a single administrative authority or owner. The devices that operate in the same administrative domain share common security features that are administered across the domain. It is an issue how to distribute the context to the middle-boxes that need the context, since the operator domain where the hand-over occurred may be unaware of the particular middle-boxes that are located in another provider's or operator's domain. Therefore, one problem to be solved is how to make context available even in such situations.
The generalized context transfer problem is stated as follows. In a multi-domain, multi-access IP network there is a need for a method to re-establish context associated with a flow when the end-to-end path changes. The path change is typically due to mobility, but can also be caused by access re-selection (which can be performed for a stationary mobile node as well).
The main requirements on the context re-establishment are:                It should facilitate seamless hand-over and therefore it should be possible to execute such context re-establishment as fast as possible.        It should be applicable to paths that contain middle-boxes. These middle-boxes may or may not be split into an Agent and general middle-box-box part as in(see ref. [6]).        It should be independent of the information elements that define the context. For instance, a QoS context can be described by the so called QoS (wireless) hints, as in reference [8], but these information elements should be transparent to the actual context re-establishment procedure and the employed context transfer protocols.        It should minimize the necessary involvement of the mobile node. In particular it should allow that the mobile node does not need to re-signal context information upon AR change, thereby facilitating efficient use of spectrum resources in wireless scenarios.        It should allow scenarios where the context needs to be re-established in several administrative domains.        
In simple terms, the problem that the current invention addresses is to define a context transfer procedure that meets the above requirements and the object of the present invention is to provide a solution to the stated problem.